Repository navigation
ci: cap build jobs at 3 hours and retry the sbom commit on a moved main - #82
Merged
Merged
Conversation
Nineteen build jobs last month ran to GitHub's 6-hour limit; none of those repos builds in more than 41 minutes, they had hung. A new build_timeout input (default 180, the slowest real build is about 150) cancels them at 3 hours and applies to build-linux too. commit-sbom committed and then rebased, and failed 17 times a month when another commit landed on sbom.json first. It now keeps this run's files aside, resets to the current tip, lays them on top and pushes, retrying up to five times. The newest build's SBOM is the truth, there is nothing to merge. When only the generated timestamp changed the SBOM is left alone and just the generated files are committed.
Each tag in sbom.json carries its own generated timestamp, so the comparison that was meant to keep no-op rebuilds silent never matched and every run committed two timestamps.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Nineteen build jobs last month ran to GitHub's 6-hour limit; none of
those repos builds in more than 41 minutes, they had hung. A new
build_timeout input (default 180, the slowest real build is about 150)
cancels them at 3 hours and applies to build-linux too.
commit-sbom committed and then rebased, and failed 17 times a month
when another commit landed on sbom.json first. It now keeps this run's
files aside, resets to the current tip, lays them on top and pushes,
retrying up to five times. The newest build's SBOM is the truth, there
is nothing to merge. When only the generated timestamp changed the
SBOM is left alone and just the generated files are committed.